IBIS Macromodel Task Group Meeting date: 11 February 2020 Members (asterisk for those attending): Achronix Semiconductor: * Hansel Dsilva ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Todd Bermensolo Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Justin Butterfield took the minutes. Hansel Dsilva from Achronix introduced himself. He is working on high-speed SerDes development at Achronix. He joined the meeting, since he has interest in improving SerDes modeling with IBIS-AMI. Arpad asked Hansel if he is a model maker or model user. Hansel replied he does both model development and uses the models. Michael noted Hansel co-presented at the DesignCon IBIS Summit. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 5 meeting. Michael moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- Discussion on “Gap in IBIS for sampling with statistical mode AMI models”: Michael suggested to discuss Walter's comments and suggestions sent over email. Walter summarized the potential issues starting on slide 14 of the DesignCon IBIS Summit presentation. Walter noted, on slide 14, there are 6 EDA tool results. Four of the results seem to agree on the eye contour, while two results are outliers. The cursor placement is not the same in any of the tools. Slide 15 shows the same story, where the clock is not placed in the correct place. Michael noted it is the sampling that is the issue. Hansel agreed the clock sampling location is an issue in the statistical flow. Walter noted the standard flow only requires passing in the impulse response. The EDA tools may give different answers with the same model and the same channel. There are several standard ways of aligning the clock. Different specifications such as PCI and DDR5 define how to make these measurements at specific contours. SiSoft uses rules that are specified as part of the channel transfer nets, and the simulation will have the standard's rules applied to the transfer nets. He noted other EDA tools may do this differently. The same model can be used for different standards, where the I/O will support different standards with different rules. Walter stated there is nothing in the AMI standard that prevents the model maker from reporting eye metrics. Arpad commented, in time-domain simulation, the sampling position is generated by the CDR and relayed with clock ticks. He asked if we are lacking this capability for statistical. Walter replied the model can return where it thinks the sampling should occur. Arpad stated, in the time-domain, this done by the model, and he asked if the model should also do this for the statistical domain. Walter noted there could be a reserved parameter for the model to output the sample point. Michael commented there is an assumption that the EDA tool will build the pictures from the model raw data output. GetWave has the clock_ticks information, and having information about where the DFE is making its decision would be very useful for statistical simulation. This would require some knowledge of the sampling specification which would need to be supplied. Michael would like to see a way for the model to specify the sampling point. Hansel noted the COM eye on slide 16 is much smaller than the EDA tool eyes, which shows how the sampling can effect the eye diagram. Walter commented COM only calculates the data at the center of the eye, so it is not calculating the eye contour. Hansel noted there has been an update in the COM tool which takes into account the position of the DFE cursors and can output the eye opening. Walter noted this is the COM tool, but this is not in the COM standard. Walter noted there is an IEEE standard for COM, but the COM tool goes beyond the specification. There is no reason the COM tool would be any better than any of the other EDA tools. The COM tool and the COM signal to noise analysis calculation methods are independent. Arpad asked how can we improve on this situation and whose responsibility is it to output the sampling. Walter noted the model could return where the sampling location is, but this is not trivial. The other option is to have a standard to reflect how the tools should analyze the model results to determine the sampling point. Another possibility is to have a reserved parameter to specify where to place the clock. Walter noted he likes the idea of having the model tell the EDA tool where to place the clock in the statistical flow. Arpad suggested for everyone to think about these options, and he would call for a straw man poll in a future meeting. Michael and Walter agreed this would be a good approach. DDR Clock Forwarding: Fangyi noted last week there were some questions, so he has added slides to address the questions. He added a slide to address the simulation flow and the necessary steps. He included crosstalk for DQ and DQS. The first step is to compute the analog channel response. The second step is to compute the DQS Rx DLL output. The third step is to use the GetWave2 function for the DQ Rx DLL with the output DQS Rx DLL. Walter commented the skew at the latch inside the DRAM is critical. If you have the DQ with the two inputs for DQ and DQS, the model can have two independent internal paths. He would much prefer to have one DLL for both DQ and DQS. Fangyi noted he has updated the proposal to include the delay between DQ and DQS. Walter asked how the delay is known in the Rx DLL. Fangyi replied it is up to the model developer. The model maker could bypass the DQS DLL and go directly to the DQ DLL. Walter stated it would be much simpler for the EDA tool to have one DLL. Fangyi commented you still need the DQS DLL for anything the model maker wants to model in the DQS path. Walter noted the tool can pass in the waveforms from the DQ and DQS into the DLL. Fangyi does not want to exclude the model maker from having the DQS model have its own functionality. Ambrish asked if the AMI model can process the analog waveform from the DQS. Fangyi stated the DQS can be a pass through. Ambrish asked if clock_ticks can be used as an input to the DQ DLL. Fangyi replied that the clock_ticks do not relay the slew rate information. Walter noted clock_ticks could be made to have enough samples to include the whole waveform. We could either create a new function or use clock ticks to input the waveform. Fangyi proposed to add a new function, so as to not confuse what we already have in the standard. Walter agreed this is a detail we can work out. Walter commented there is no reason that the GetWave blocks for DQ and DQS to not be the in the same function. There could be some delay due to the processing, and the samples coming in could be different from the samples coming out. Walter noted it is critical to model the DQS delay to the slicer, it is important to get this correct in the simulation architecture. Adding the DQS DLL in the path could be problematic. Arpad asked, since the model maker is making both DQ and DQS models, this can be made to work. Walter noted the DQS DLL would only have a CTLE. He asked Michael and Randy for their thoughts. Randy replied he would have to think about it. Michael replied he would have to discuss the issue internally. BIRD201: Walter suggested a library of protocols as an ongoing discussion topic. New BIRDs from Editorial Task Group? Arpad asked if this can be removed from the agenda. Bob suggested to keep it. Walter asked if Bob wanted to take ownership of this. Bob stated this is a a possibility, but progress would be slow. Jitter HF/LF components and Jitter Amplification: Arpad asked Michael about this topic. Michael would like to keep this topic on the list for future discussion. Tabled ARs: Arpad asked if we should keep the tabled ARs for Michael and Randy. Michael stated we are already in these discussions on the clocking and protocols. Randy agreed. Michael suggested these can be deleted. - Michael M.: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 18 February 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives